Tests: Dump process state when a session-history wait times out - #11021
Closed
sideshowbarker wants to merge 1 commit into
Closed
Tests: Dump process state when a session-history wait times out#11021sideshowbarker wants to merge 1 commit into
sideshowbarker wants to merge 1 commit into
Conversation
Problem: TestWebDriverSessionHistory intermittently timed out on the Linux x86_64 Release GNU CI job in the cross-process no-content navigation-restore subtest. The harness waits 30s for the restored /a document — which never loads. https://github.com/LadybirdBrowser/ladybird/actions/runs/30988508142 https://github.com/LadybirdBrowser/ladybird/actions/runs/30999552155 https://github.com/LadybirdBrowser/ladybird/actions/runs/31042505962 https://github.com/LadybirdBrowser/ladybird/actions/runs/31082213133 Cause: Session-history debug traces from failed runs show the navigation engine doing everything right: the 204 response abandons the provisional cross-site load, the UI receives the cancel, restores previous session history, and begins replacing the provisional WebContent process. The trace then stops mid-replacement. In 3 of 4 failures examined, the last line is the dump written just before the UI spawns the replacement process — a window whose only blocking operations are unbounded sync IPC round-trips to RequestServer, ImageDecoder, and the Compositor — plus the Linux fork helper’s blocking read that waits for the child to exec. In the 4th, the spawn completed — but the fresh WebContent process never processed a single queued IPC message; its first action is itself an unbounded sync IPC call to the UI process. Every one of those waits is silent and has no deadline — so whichever wedges, the failure presents as a clean-looking 30s timeout with no evidence of who was stuck where — the captured logs can’t distinguish the candidates. Fix: When a wait_for_event wait or a WebDriver HTTP request times out, walk the WebDriver’s process tree via /proc — while the wedged processes are still alive — and print every thread’s name, state, wchan, and current syscall to stderr. Reading /proc doesn’t perturb the processes, works in the CI container, and the next occurrence will show exactly which thread of which process is parked in which blocking call. On macOS (no /proc) and on the passing path, the harness behavior is unchanged.
📝 WalkthroughWalkthroughThe test records the WebDriver PID and adds ChangesWebDriver timeout forensics
Sequence Diagram(s)sequenceDiagram
participant Test as test-webdriver-session-history.py
participant WebDriver as WebDriver subprocess
participant Proc as /proc filesystem
Test->>WebDriver: spawn and record PID
Test->>WebDriver: wait for event or HTTP response
WebDriver-->>Test: timeout
Test->>Proc: inspect descendant processes and threads
Proc-->>Test: return forensic details
Test-->>Test: print diagnostics and re-raise timeout
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Member
Author
|
Closing. #11028 is the fix for the cited CI failures. And while I’d imagined this’d be able to dump out info that’d lead to a solution for those CI failures (or similar ones that might come along later), in the end it proved to be useless for those. So it’s a solution for a problem that it turns out we never actually had to begin with. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem:
TestWebDriverSessionHistoryintermittently timed out on the Linux x86_64 Release GNU CI job in the cross-process no-content navigation-restore subtest. The harness waits 30s for the restored/adocument — which never loads.Cause: Session-history debug traces from failed runs show the navigation engine doing everything right: the 204 response abandons the provisional cross-site load, the UI receives the cancel, restores previous session history, and begins replacing the provisional WebContent process. The trace then stops mid-replacement. In 3 of 4 failures examined, the last line is the dump written just before the UI spawns the replacement process — a window whose only blocking operations are unbounded sync IPC round-trips to RequestServer, ImageDecoder, and the Compositor — plus the Linux fork helper’s blocking read that waits for the child to
exec. In the 4th, the spawn completed — but the fresh WebContent process never processed a single queued IPC message; its first action is itself an unbounded sync IPC call to the UI process. Every one of those waits is silent and has no deadline — so whichever wedges, the failure presents as a clean-looking 30s timeout with no evidence of who was stuck where — the captured logs can’t distinguish the candidates.Fix: When a
wait_for_eventwait or a WebDriver HTTP request times out, walk the WebDriver’s process tree via/proc— while the wedged processes are still alive — and print every thread’s name, state,wchan, and current syscall to stderr. Reading/procdoesn’t perturb the processes, works in the CI container, and the next occurrence will show exactly which thread of which process is parked in which blocking call. On macOS (no/proc) and on the passing path, the harness behavior is unchanged.